cancel_inter_task_stream_read issues a synchronous stream.cancel-read on the
inter-task wakeup stream while that stream is still a member of the task's
waitable set, calling remove_waitable only afterwards:

unsafe {
    UnitStreamOps.cancel_read(handle);   // sync cancel — stream still in the set
}
self.remove_waitable(handle);            // removed afterwards

Per component-model#647, a synchronous {stream,future}.cancel-{read,write}
must trap if the waitable is still in a waitable set, for the same reason the
synchronous read/write operations do (the cancel may need to block on the very
waitable the set is watching). The canonical ABI codifies this as
trap_if(e.in_waitable_set() and not async_).

The general cancellation path in WaitableOperation::cancel already respects
this — it calls unregister_waker (removing the waitable from the set) before
invoking the synchronous cancel intrinsic. cancel_inter_task_stream_read is
the one place that doesn't follow that ordering, so on a runtime that enforces
the trap it faults during ordinary async operation.

This reorders the two operations so the stream leaves the waitable set before
the synchronous cancel, matching the established unregister-then-cancel pattern.
The cancel's return code is discarded exactly as before, so behavior is
otherwise unchanged.

Context / testing

This surfaced while implementing the corresponding cancel traps in Wasmtime
(bytecodealliance/wasmtime#13690): once Wasmtime traps on a synchronous cancel
of an in-set waitable, every wasi:http@0.3.0 (p3) program built with this
runtime traps in cancel_inter_task_stream_read. With this change applied
(via a local [patch.crates-io]), Wasmtime's full p3 HTTP/CLI suites pass
again (52 previously-failing tests across wasmtime-wasi/wasmtime-wasi-http).